The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Frame Relay refers to a packet-switching protocol for connecting devices in a network. Frame Relay is becoming more popular, in part because it is a relatively economical and high throughput environment. Presently, frame relay networks in the United States support data transfer rates at T-1 (1.544 Mbps) and T-3 (45 Mbps) speeds, enabling many service providers to utilize existing T-1 and T-3 lines to provide network services. Another network technology, Asynchronous Transfer Mode (ATM), uses fixed size cells or packets to transfer data. By using a small, constant cell size, ATM equipment is able to transmit video, audio, and computer data over the same network, without any single type of data taking up a large amount of the available bandwidth of the line. In general, subscribers to network services that are provided by a service provider use a network device, such as a router or gateway, to connect a personal computer or other end station to the service provider's network and obtain service.
Automatic network configuration provisioning systems are now available for use in generating and downloading sets of configuration instructions, or configuration files, for network devices that are deployed in the field to subscribers of services provided by service providers. It is desirable to be able to perform such provisioning automatically, without requiring a subscriber to manually enter configuration commands, and without requiring a technician associated with a network service provider to visit the subscriber and configure the device.
In one example approach, a vendor manufactures customer premises equipment (CPE) network devices, and “drop-ships” the CPEs to the premises of subscribers of a network service provider. The CPEs are shipped with a generic bootstrap configuration that is copied from or generated at the vendor based on a standard template or format specified by the service provider. When a subscriber installs and powers-up a CPE, under control of the bootstrap configuration the CPE uses an interface specified in the bootstrap configuration to contact a configuration server associated with the service provider. The configuration server downloads a permanent, application-specific configuration to the CPE, which executes the received configuration and begins normal operation.
In network environments in which frame relay and ATM technologies are present, however, the technique of using a generic bootstrap configuration is presented with new issues. The Datalink Connection Identifier (DLCI) number corresponding to a network Persistent Virtual Circuit (PVC) is unique per interface presented to a given customer premises and is insignificant and independent of the DLCI name space used on other interfaces presented to other customer premises. The choice of DLCI number presented to a given customer premises is technically arbitrary, dependant on the choice of service provider and its internal policies.
Using a fixed preset DLCI in any generic bootstrap configuration, for example, would fail in instances where such devices must establish connectivity across multiple regions or service providers using disparate DLCI numbering conventions. In such situations, the DLCI number presented to CPE devices in the customer premises is heterogeneous throughout the network and there cannot be any assumption made about its value with respect to what is encoded in the bootstrap configuration. In frame relay networks, for example, packets are routed through one or more permanent virtual circuits (PVCs), which may be identified using different DLCIs. Since each DLCI is a permanently configured switching path to a particular destination, a system may have more than one DLCI configured. The appropriate DLCI for any particular connection varies between branch offices as well. Accordingly, in such applications, merely shipping a CPE with a generic configuration having therein, a preset DLCI would not address the problem sufficiently in all cases. Therefore, to date, there has been no way to automate the configuration of network devices with templates.
Based on the foregoing, there is a clear need for an approach for automatically provisioning network devices for use in environments, characterized by heterogeneous network technologies.
There is a specific need for an approach that can deliver a consistent configuration to a variety of devices, including modular devices, for use with a variety of network technologies.
There is also a particular need for an automated configuration approach that is compatible with drop shipment practices.